Walkthrough 10-7: Review and integrate with APIkit error handlers

In this walkthrough, you connect the application’s implementation to the interface and ensure all the error handling works. You will:

·       Review the error handlers generated by APIkit.

·       Review settings for the APIkit Router and HTTP Listener in the APIkit generated interface.

·       Connect the implementation to the interface and test the error handling behavior.

·       Modify implementation error scopes so they work with the APIkit generated interface.

Starting file

If you did not complete the previous walkthrough, you can get a starting file here. This file is also located in the solutions folder of the student files ZIP located in the Course Resources.

Review APIkit generated error handlers

1.     Return to apdev-flights-ws in Anypoint Studio.

2.     Open interface.xml.

3.     Review the error handling section in mua-flights-api-main.

     

4.     Review the types of errors handled by each error handler scope.

5.     Navigate to the Transform Message properties view for the first error handling scope.

6.     Review the expression that sets the payload.

7.     Use the output drop-down menu to change the output to Variable – httpStatus.

8.     Review the expression that sets an httpStatus variable; you should see that for a bad request the httpStatus variable is set to 400.

Review settings for the APIkit Router

9.     Navigate to the properties view for the APIkit Router in mua-flights-api-main.

10.  Click the Edit button next to router configuration.

11.  In the Global Element Properties dialog box, locate the HTTP status var name setting; you should see httpStatus.

12.  Click OK.

Review settings for the HTTP Listener

13.  Navigate to the Responses tab in the properties view for the HTTP Listener in mua-flights-api-main.

14.  Review the response body and status code.

15.  Review the error response body and status code.

Connect the interface to the implementation

16.  In interface.xml, locate the get:\flights flow.

17.  Review the default transformation in this flow.

18.  Delete the Transform Message component.

19.  Add a Flow Reference component to the flow.

20.  In the Flow Reference properties view, set the flow name and display name to getFlights.

21.  Return to implementation.xml.

22.  Delete the GET /flights Listener in getFlights.

23.  Save all the files to redeploy the application.

Test the application

24.  In Advanced REST Client, make another request to http://localhost:8081/flights?code=PDX; you should get a 404 response with a no listener message.

25.  Add /api to the URL and make a request to http://localhost:8081/api/flights?code=PDX; you should get the United flights to PDX as before.

26.  Change the code to make a request to http://localhost:8081/api/flights?code=FOO; you should now get a 400 Bad Request response instead of your custom message.

 

27.  Remove the code to make a request to http://localhost:8081/api/flights; you should now get your custom error message.

28.  Add the airline and code to make a request to http://localhost:8081/api/flights?airline=american&code=PDX; you should now get a 200 response with the bad request description in the error message.

Review the API

29.  Return to Anypoint Studio and stop the project.

30.  Return to mua-flights-api.raml and review the code; you should see the code query parameter is not required but it has allowed values enumerated.

Debug the application

31.  Return to interface.xml.

32.  Add a breakpoint to the APIkit Router in mua-flights-api-main.

33.  Debug the project and proceed through any errors in the workspace.

34.  In Advanced REST Client, make another request to http://localhost:8081/api/flights?airline=american&code=PDX.

35.  In the Mule Debugger, watch the payload and variables and step through the application.

36.  Step back to the APIkit router.

37.  Review the exception, the payload, and the variables.

 

38.  Resume through the rest of the application.

39.  In Advanced REST Client, change the code to make a request to http://localhost:8081/api/flights?airline=american&code=FOO.

40.  In the Mule Debugger, step through the application; the APIkit router should immediately throw an error.

41.  Step again; you should see the error is handled by the APIKIT:BAD_REQUEST handler.

42.  Resume through the rest of the application.

43.  In Advanced REST Client, remove the airline and code to make a request to http://localhost:8081/api/flights.

44.  In the Mule Debugger, step through the application; the validator should throw an error and execution should not return to the APIkit router.

45.  Return to Advanced REST Client; you should successfully get a 400 response with the custom message.

Note: If you had specified the code query parameter to be required in the RAML file from which the interface was generated, the APIkit router would catch this immediately and respond with a 400 Bad Request response. The event would never get to the validator in your implementation.

Change the American flights error scope to On Error Continue

46.  Return to Anypoint Studio and switch to the Mule Design perspective.

47.  Return to implementation.xml.

48.  Locate the error handler in the getAmericanFlights flow.

49.  Right-click it and select Go To XML.

50.  Change the on-error-propagate start and end tags in the getAmericaFlights flow to on-error-continue.

 

51.  Change the doc:name in the start tag to On Error Continue.

52.  Switch back to the Message Flow view; you should now see an On Error Continue.

Change the global default error scopes to On Error Continue

53.  Return to global.xml.

54.  Review the types of error handler scopes.

 

55.  Right-click the WSC error handler and select Go To XML.

56.  Change the four on-error-propagate start and end tags to on-error-continue.

57.  Change the doc:names in both start tags to On Error Continue.

58.  Switch back to the Message Flow view; you should now see both are On Error Continue scopes.

 

Set the HTTP status code for the On Error Continue scopes so you do not get 200

59.  Add a Set Variable transformer to the WSC error handler.

60.  In the Set Variable properties view, set the display name and name to httpStatus.

61.  Set the value to 500.

62.  Copy the Set Variable transformer and add it to the ANY error scope.

63.  Set the display name to httpStatus.

 

Test the application

64.  Save the files to redeploy the project.

65.  In Advanced REST Client, add the airline and code to make a request to http://localhost:8081/api/flights?airline=american&code=PDX.

66.  In the Mule Debugger, step through the application; the application now does not return to the APIkit router.

67.  Return to Advanced REST Client; you should now get a 200 response with the No flights to PDX message.

68.  In Advanced REST Client, change the airline to make a request to http://localhost:8081/api/flights?airline=delta&code=PDX.

69.  In the Mule Debugger, step through the application.

70.  Return to Advanced REST Client; you should now get the 500 response with the data unavailable message.

71.  Return to Anypoint Studio and switch perspectives.